In an H.323 protocol-based multi-point double-stream video-conferencing system, a centralized conference mode exists. This mode is the most widely used mode. In this mode, the video and audio streams on each conference terminal in a conference are controlled by a Multipoint Control Unit (MCU) in a centralized way. All the conference terminals participating in the conference set up calls with only the MCU, and send the code streams including the main stream and auxiliary stream to the MCU. The MCU performs necessary processing for the code streams, and selectively sends the code streams to each conference terminal. In addition, the MCU sends conference control signaling to each conference terminal and controls the exchange and transmission of video and audio code streams to implement the specific conference control function.
With the existing technology, the double-stream function of the multi-point double-stream video-conferencing system is implemented in compliance with the H.239 standard protocol. The H.239 protocol describes how to control and indicate the auxiliary stream through H.245 signaling and the capability exchange mechanism in an H.323 protocol-based video-conferencing system. A presentation type of auxiliary stream exists in the multi-point double-stream video-conferencing system. The auxiliary stream is controlled in the role management process. Specifically, for a presentation type of auxiliary stream, the role management process is based on the token mechanism. That is, a specific auxiliary stream token must be obtained before the conference terminal in a conference sends the local auxiliary stream. At any time, only one conference terminal holds the token in a conference to send the auxiliary stream.
As stipulated by the H.239 protocol, in a multi-point double-stream conference system, the MCU controls the delivery of the auxiliary stream token. That is, each conference terminal must request an auxiliary stream token from the MCU before sending the auxiliary stream. The MCU determines whether the token can be delivered to the requesting conference terminal based on the holding of the token in the current conference. After receiving a token response from the MCU, the conference terminal can open the auxiliary stream channel to send the auxiliary stream and periodically send a message indicating the holding of the token to the MCU. The MCU forwards the message to all the conference terminals in the conference. When a conference terminal wants to release the token without sending the auxiliary stream, the terminal sends a token release indication to the MCU. After receiving the indication, the MCU deems that the auxiliary stream token in the current conference is in the idle state, and other conference terminals can apply to the MCU for the token.
During the implementation of the present invention, the inventor discovers the following disadvantages in the existing technology:
In many actual application scenarios, the MCU needs to forcibly deprive the token from a conference terminal in a conference and then deliver the token to another conference terminal, so that the conference terminal can obtain the auxiliary stream token smoothly. For example, when a conference terminal in a conference needs to present an important film image to participants, but the auxiliary stream token in the current conference is occupied by another conference terminal for a long time and cannot be released instantly. As a result, the conference terminal cannot obtain the right to send the auxiliary stream in time, thus affecting the conference progress. In the H.239 protocol, token request and release mechanisms are regulated, but no token depriving mechanism is described. In this case, the MCU as the conference control center fails to control the release of an auxiliary stream token in the conference and cannot fully control the auxiliary stream token. In serious cases, for example, when an exception occurs on the conference terminal with the token, a conference has to be held again.